Core Question

Zero Trust 在 User、Agent runtime、model、MCP、Tool 與 Resource 之間具體要驗證什麼？

今天的問題

企業把 Agent runtime、MCP server 和資料庫放在同一個 cluster，於是「內網來源」被當成可信。模型收到外部文件後改選 Tool；Agent 直接用 pod secret 呼叫 API。網路位置沒有改變，但 authority 已跨過多個邊界，卻沒有人重新驗證。

為什麼這不是傳統 IAM 問題

NIST SP 800-207 的核心是保護 resource、workflow 與 service，不把 network location 當作主要信任依據。NIST SP 800-207 套到 Agent 還必須問：模型輸出是否被當成 authority？Tool result 是否能改變 delegation？每一個自主規劃步驟是否重新帶上 actor、subject、task 與資料流 context？這些是 Agent 才會出現的 control-plane/data-plane 混淆。

Threat / Failure Scenario

攻擊者控制 MCP tool description 或 Tool output，誘使 Agent 呼叫 export_sensitive。因為 Gateway 只驗證 cluster identity，且 Tool 信任任意內網 header，Action 成功。這裡沒有缺少登入；缺的是對每次 authority crossing 的 explicit verification、least privilege 和 enforcement。

攻擊者控制 MCP tool description 或 Tool output，誘使 Agent 呼叫 export_sensitive。若 Gateway 只驗證 cluster identity，內網來源就會被錯當成足夠 authority。

核心概念

Zero Trust for Agents 的最小單位不是「每個服務加 login」，而是每次跨 boundary 都驗證：who（User subject、Agent actor、runtime assurance）、what（canonical Action/resource）、why（delegation purpose/task）、under what（policy、risk、expiry、data egress）以及 what happened（outcome/evidence）。

Model 是不受信任的 planner，不是 principal；MCP 是 protocol surface，不是 permission grant；network segmentation 是減少旁路的條件，不是 allow。Workload identity 可用短效、attestation-based 的 SPIFFE SVID；SPIFFE 規格描述 workload 如何取得短生命 cryptographic identity 與互相驗證。SPIFFE Overview

Architecture Pattern

Naive / Unsafe Design

same cluster/network = trusted
Agent -> MCP -> Tool -> Resource
shared secret + X-Agent-Id header

Recommended Design

Trust zones 是 User session、Agent runtime、model context、authorization plane、MCP/Tool zone、Resource zone；每條箭頭都要有明確的 proof/context。Identity flow 為 User Identity + workload identity + delegation → Gateway/PDP → constrained MCP/Tool call。Authorization Decision Point 在 PDP，PEP 在 Gateway，Resource 可做第二層檢查。MCP 不應繞過 PEP。

小型 PoC

def authorize(req):
    required = {"subject", "actor", "task", "action", "audience"}
    if not required <= req.keys(): return "deny:missing-context"
    if req["audience"] != "tool:crm": return "deny:wrong-audience"
    if req["action"] == "crm.read" and req["task"] == "t-29": return "allow"
    return "deny:policy"

good = {"subject":"alice", "actor":"spiffe://corp/agent/ops/i-1",
        "task":"t-29", "action":"crm.read", "audience":"tool:crm"}
bad = {**good, "action":"crm.export_sensitive"}
assert authorize(good) == "allow"
assert authorize(bad).startswith("deny")
print(authorize(good), authorize(bad))

這個 boundary walkthrough 實際驗證一條 allow 與一條 deny；它沒有驗證 SPIFFE issuer、mTLS 或真實 MCP 實作，因為本篇要證明的是「內網位置不能取代每次 decision」。

今天得到什麼

• Zero Trust 要保護的是 Agent Action 與 Resource，不是只保護網段。
• Model、MCP tool listing、Tool output 都不是 authority proof。
• 每次跨界應帶上可驗證 actor、subject、task、Action、audience 與 policy context。
• Workload identity、segmentation、PEP、PDP 與 resource check 是互補控制。

下一篇

最後一天把 identity、delegation、policy、approval、revocation、Zero Trust 與 evidence 收斂成一套 Enterprise Agent Identity & Authorization Reference Architecture，並用端到端 PoC 驗證它。

參考資料

• NIST SP 800-207 Zero Trust Architecture
• SPIFFE Overview
• NIST SP 800-207A